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AUTOMATED DEVELOPMENT SYSTEM 
FOR DEVELOPING APPUCATIONS THAT 
INTERFACE WITH BOTH DISTRIBUTED 
COMPONENT OBJECT MODEL (DCOM) 
AND ENTERPRISE SERVER 
ENVIRONMENTS 

CROSS REFERENCE TO CO-PENDING 
APPLICATIONS 

The present application is related to U.S. patent applica- 
tion Sen No. 09/164,932, filed Oct. 1, 1988, entitled "A 
MULTI-CUENT USER CUSTOMIZED DCOM GATE- 
WAY FOR AN OLTP ENTERPRISE SERVER 
APPLICAnON", and application Set. No. 09/164,759, filed 
Oct. 1, 1998, entitled "A COMMON GATEWAY WHICH 
ALLOWS APPLETS TO MAKE PROGRAM CALLS TO 
OLTP APPLICATIONS EXECUTING ON AN ENTER- 
PRISE SERVER", both of which arc assigned to the 
assignee of the present invention and incorporated herein by 
reference. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to a comnnunications gate- 
way for providing access to an enterprise server application 
from a Distributed Component Objea Model (DCOM) 
environment, and more specifically, to a gateway utility 
which provides an interactive interface to simplify the 
building of functions to access an enterprise On-Une Trans- 
action Processing (OLTP) application from a DCOM envi- 
ronment. 

2. Description of the Prior Art 

Hie methods by which companies conduct business with 
their customers are undergoing fundamental changes, due in 
large part to World Wide Web technology. In addition, the 
same tecbnolc^y that makes a company accessible to the 
world, may be used on internal company networks for 
conducting operational and administrative tasks. 

One of the technologies underlying the World Wide Web 
is the Web Browser. Web Browsers have become a de facto 
user interface standard because of their ability to interpret 
and display information having standard formats (e.g., 
HyperText Markup Language (HTML), standard test, GIF, 
etc.). Client software programs, popularly referred to as Web 
Browsers (e.g., Mosaic, Netscape Navigator, Microsoft 
Internet Explorer, etc.), execute on client systems and issue 
requests to server systenas. The server systems typically 
execute HyperText Transport Protocol (HTTP) server pro- 
grams which process requests from the Web Browsers and 
deliver data to them. The system that executes an HTTP 
server program and returns data to the Web Browser will 
hereinafter be referred to as a Web Server System. An HTTP 
server program itself will be referred to as a Web Server. 

A Web Server System has access to on-line documents 
that contain data written in HyperText Markup Language 
(HTML). The HTML documents contain display 
parameters, capable of interpretation by a Web Browser, and 
references to other HTML documents and Web Servers 
(source: World Wide Web: Beneath the Surf, from UCL 
Press, by Mark Handley and Jon Crowcroft, on-line at 
http://www.cs.ucl. ac.uk/stafi^on/book/book.html). 

As Web Browsers are making their mark as a "standard" 
user interface, many businesses have a wealth of information 
that is managed by prior art data base management systems 
such as DMS, RDMS, DB2, Oracle, Ingres, Sybase, 
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Informix, and many others. Id addition, many of the data- 
base management systems are available as resources in a 
larger transaction processing system. There are also mission 
critical applications which still reside on enterprise servers, 
5 since these type of systems have resiliency and recovery 
features historically not available on other smaller types of 
servers. 

One key to the future success of a business may lie in its 
ability to capitalize on the growing prevalence of Web 

10 Browsers in combination with selectively providing access 
to the data that is stored in its databases. Common Gateway 
Interface programs are used to provide Web Browser access 
to such databases. 
The Common Gateway Interface (CGI) is a standard for 

15 interfacing external applications, such as Web Browsers, to 
obtain information from information servers, such as Web 
Servers. The CGI allows programs (CGI programs) to be 
referenced by a Web Browser and executed on the Web 
Server system. For example, to make a UNIX database 

20 accessible via the Worid Wide Web, a CGI program is 
executed on the Web Server system to transmit information 
to the database engine, receive the results from the database 
engine, and format the data in an HTML document which is 
returned to the Web Browser. 

25 A disadvantage with the CGI program approach described 
above is that the application developer must be intimately 
acquainted with the HTML, the CGI, and the database 
engine. In addition, a different CGI program may be required 
for each different database, thus adding to the cost of 

30 creating and maintaining the database access for the Web 
Browser. Thus, the application developer is required to 
understand multiple types of systems, and must also under- 
stand how these systems interface. The learning curve for 
this type of development is therefore undesirably long. 

SUMMARY OF THE INVENTION 

The present invention overcomes many of the disadvan- 
tages associated with the prior art by providing a utility with 
an interactive interface that simplifies building transaction 

40 gateway functions to access an enterprise server based 
On-Line Transaction Processing (OLTP) application from a 
Distributed Component Object Model (DCOM) environ- 
ment. Thus, the automated development system of the 
present invention allows developers to more easily incorpo- 

45 rale functionality from enterprise-based applications within 
an application running on a DCOM-bascd platfonn. 

In order to utilize the present invention, a developer must 
first create a service on the enterprise server. An example of 
a service may be retrieval of data from a database associated 

50 with the enterprise On-Lioe Transaction Processing (OLTP) 
system. After the service has been developed, the developer 
transfers the service input and output "view files" to a 
location where they can be accessed by the DGateAce utility 
of the present invention. In a preferred embodiment, this 

55 location is a >\^odows NT workstation. The "view files" 
contain a description of the parameters used for transaction 
requests and responses. In other words, the input view file 
includes information on what the input parameters are and 
how they must be formatted for the service, and the output 

60 view file includes information on what the output parameters 
are and bow they are formatted by the service to the external 
user. A single view file could be used for both the input and 
output parameters for a transaction, separate view files could 
be used for both input and output parameters, or a single 

65 view file could be used for only input parameters. 

Upon invocation, the DGateAce utiUty extracts the inter- 
face information from the view files and automatically 
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generates a source file lhat is compatible with the DCOM shows ioterrelationship between interactive user queries and 
environment. This source file is subsequently used in the the function definition, 
creation of a DCOM Server. During the source file genera- 
tion process, the DGateAce utOity queries the user for the DETAILED DESCRIPTION OF THE 
type of client(s) that will be using the Server so that the 5 PREFERRED EMBODIMENTS 
Server is tailored for receiving requests from those types of . , ^ . . ... u- u f u ™^^«t^^ 
Clients. These Clients may include Visual Basic, c/4., Web , ^hf cfcscnptions which foUow are presented 
Browsers with Active Server Pages (ASPs), or other types of largely m terms of algorithms and symbohc representations 
Client applications. After the DCOM Server has been sue- of operations on data bits withm a computer memory. These 
ccssfully generated, the developer must then develop an . . algorithmic descnptions and representations are the means 
application (Client) running within the DCOM environmem. used by those skilled in the data processing arts to most 
When a standard call is made from a DCOM Chent appli- effectively convey the substance of their work to others 
cation to an enterprise -based On -Line Transaction ftocess- skilled in the art. 

ing service, the following steps will occur: First, the request An algorithm is here, generally, conceived to be a self- 
will pass from the DCOM Client to the DCOM Server. The consistent sequence of steps leading to a desired result. 
Server will correctly format (pack) the request parameters. These steps arc those requiring physical maoipulations of 
and pass the request onto the DGate__Server.dll Dynamic physical quantities. Usually, though not necessarily, these 
Link Library (DLL). The Dynamic Link Library (DLL), quantities take the form of electrical or magnetic signals 
verifies that the input parameters can be read, and verifies capable of being stored, transfcned, combined, compared, 
that the output parameters can be written. The DLL then and otherwise manipulated. It proves convenient at times, 
appends required additional parameters to the request and principally for reasons of common usage, to refer to these 
forwards the request to the DGate.Exe (the DCOM signals as bits, values, elements, symbols, characters, terms. 
Gateway) component. This DCOM Gateway executable numbers or the like. It should be kept in mind, however, that 
uses parameter information to correctly forward the request all of these and similar terms are to be associated with the 
to the OLTP service on the enterprise system. The requested appropriate physical quantities and are merely convenient 
service is performed on the enterprise system, and a labels applied to these quantities. 

response is sent back to the DCOM Gateway executable Furthermore, the manipulations performed are often 

(DGate.Exe). The DCOM Gateway executable checks for referred to in terms, such as adding or comparing, which are 

successful completion by the OLTP service, then passes the commonly associated with mental operations performed by 

response to the Server, which correctly formats (unpacks) ^ human operator. No such capability of a human operator 

the data and passes it back to the requesting Client appli- jg necessary, or desirable in most cases, in any of the 

cation. operations described herein which form part of the present 

Inthismanner, a C, C++, Visual Basic, or some other type invention; the operations are machine operations. Useful 

of application running on an NT or Windows system is machines for performing the operations of the present inven- 

provided access to user-developed services running on an tion include general purpose digital computers, or other 

enterprise server. The developer does not need to understand similar devices. In all cases, it should be kept in mind the 

the interface between the two systems because this infor- distinction between the method operations in operating a 

mation is automatically included within the automatically- computer and the method of computation itself. The present 

generated interface software components. invention related to method steps for operating a computer 
BRIEF DESCRIPTION OF THE DRAWINGS 40 ^ processing electrical or other (e.g., mechanical, chemical) 

physical signals to generate other desired physical signals. 

Other objects of the present invention and many of the _^ . ^. , i * * * p 

i ^\ . . -iiu j.i The present mvention also relates to apparatus for per- 

atlendant advantages of the present mvention will be readily r • *u *- tt,- *, 

. . ^ . A^^*^^A K,, formmg these operations. This apparatus may be specially 

appreciated as the same becomes better understood by * . j r a •* f.««'c- i 

L r 1. ■ J . 1 J J ' u constructed for the required purposes or it may comprise a 

reference to the foUowine detailed descnption when con- , 1.1 *• * j ^ 

. , , . . . f , - J . -4*; geoeral purpose computer as selectively activated or recon- 

sidered m connection with the accompanymg drawings, m ^ ^ a\omputer program stored in the computer. The 

which like reference numerals designate like parts through- J -^J^ herein are not inherently related to a 

out the figures thereof and wherein: , , ^ ^ , 1 

^ . ^ . particular computer system or other apparatus. In particular, 

FIG. 1 is an illustration of the environment withm which ^^.^^^ ^^^^^^ p^^^^ computer systems may be used with 

the present invention operates; computer programs written in accordance with the teachings 

FIG. 2 is a high-level, generalized diagram showing of the present invention, or it may prove more convenient to 

inputs to and outputs from the function building tool construct more specialized apparatus, to perform the 

(DGateAce) of the present invention; required method steps. The required stmcture for such 

RG. 3 aiustrates how Interface Definition Language machines will be apparent fi-om the description given below. 

(IDL) files generated by the function building tool of the j illustration of the environment within which 

present invention (DGateAce) are compiled by the the present invention operates. As described in more detail 

Microsoft IDL compiler; below, the present invention is an automated development 

FIG. 4 illustrates how the output files from the fimction system which simplifies the creation of DCOM Client/ 

building tool (DGateAce) of the present invention are used Server components which interface an application running 

during the compilation and linking of the DCOM Server ^^^^^ ^i^^ DCOM environment with an enterprise based 

module; On-Line Transaction Processing (OLTP) service. The 

FIG. 5 is a diagram which indicates the interrelationships present invention is specifically developed to operate in the 

between the DGate gateway and DGateAce tool; DGate environment described in a co-pending application 

FIG. 6 is a generalized flow diagram of the process flow enritled, "A MULTI-CLIENT USER CUSTOMIZED 
of the function building tool (DGateAce); and 65 DCOM GATEWAY FOR AN OLTP ENTERPRISE 

FIG. 7 is a detailed flow diagram of the process flow of SERVER APPLICATION", which is hereby incorporated by 

the function building tool (DGateAce), which specifically reference. 
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Open/OLTP services 150 are created by a user on an DGate-Server.dll 168. The DGate-Server.dll 168 and the 
enterprise server 152, such as a Unisys 2200. These services DGate.exe 166 are the modules which "DCOM-enable" an 
150 are capable of operating under an OLTP-style transac- OLTP enterprise server 152 such as the Unisys 2200 System, 
tion processing system. In a preferred embodiment, this FIG. 2 is a high-level, generalized diagram showing 
OLTP-style system is X/Open compliant. The service 150 is 5 inputs to and outputs from the function building tool 
designed to accomplish a specific task, for example, update (DGateAce) of the present invention. The DGateAce tool 
a user's bank account balance following a debit or credit. 226 is a transaction gateway utility that provides an inter- 
Each service is associated with an input view (.v) file 158 active interface which simplifies the building of functions 
which defines how the input parameters will be provided to within a Distributed Component object Model (DCOM) 
thcservicelSO. In particular, the .V file 158 indicates where lo environment for accessing an enterprise based On-line 
each input parameter is located in the view file, and the size Transaction Processing service. The DGateAce tool 226 can 
and type of each input parameter. If a service 150 is to run on any platform that supports the Microsoft Windows 95 
provide output to the user (for example, the updated account or Microsoft Windows NT environment and has access to 
balance), another output view file is required to communi- files containing VIEW buffers for the transactions that are 
cate how the information will be presented within the output is going to be converted. DGateAce 226 receives input from 
view buffer fo^*" sources: a function template 200, one or more view 
For all services 150 that are to accessed from a particular buffer files 202, a univer^l unique identifier from a UUID 
Windows NT node 190, the associated view files 158 must generator 210. and a set of mtcractively entered mformation 
be copied (via FTP or other copy service, shown at 159) to generated by an application developer 214 From these four 
that node 190. Once the view files 158 have been success- input sources. DGateAce produces^two types of output: 
fully copied to the wr^dows NT node 190, the ViewC "it^rface definiUon language (IDL) files 222, and function 
compiler 160 is used to generate ".vv" files 162. ^^^^ .... 

Tlie PathMate DGateAce software component of the ^ ^ne of the tasks when developing an enterpme based 

present invention also must have access to the view files „ Open/OOT service ^ ^ 

158. DGateAce 172 uses the view files 158 to automatically buffer file 202 is a description of the parameters used for 

generate files needed for an appUcation to operate within a transaction requests and responses. A smgle view buffer file 

DCOM environment. These files include the DCOM Server 202 could be used for both the mput and output parame^^^^^ 

Applcation.exe 170, the Stub.dil 182, and the Proxy.dll 184. ^or a transaction, or separate view buffer files 202 could be 

THe Distributed Component Object Model (DCOM) is a 3^ used for input and output 

Microsoft model for d4ibuted object computing. Within ^ ^^^^^^^^^^^.^^^ ^ ^.T! T ^ tn 

the DCOM environment, a remote DCOM Qient AppUca- Open/OLTP view buffer files (.v) 202 to dlow developers to 

tion 186 can make a request. TTie DCOM client 186 can be f l^ct the views they want to use when defimng the functions 

any type of cUent, including a Visual Basic cUent, a C++ for a given DCOM server pmgram, T]jerefor.. these view 

cUenCor a Web Browser with Active Server Pages (ASP). If 35 ^f^'^^'^'r^^l'''.^^^^ 7^^^*'°° 

the request made by the DCOM client 186 is a request for where PathMate 228 is instaUed, ei^er on a ^^^^^^ drive or on 

access to a remote process (interprocess request) the request ^ "^t^ork drive accessible from the PathMate workstation 

is routed to proxy.dll 184. Proxy.dll 184 is a code segment ^08. 

which receives any client requests targeted for a remote DCOM requires that each interface have a umversal 

server, and will facilitate the necessary interprocess com- unique identifier (UUID). DGateAce 226 can use its UUID - 

munications. The proxy.dll 184 understands how to com- GEN utiUty 210 to generate and insert a UUID for an 

municate with the Client 186, and also understands how to interface with the dick of a button. If the Open/OLTP 

communicate over an interface 185 which is shared by two Pathway is not installed, a UUID does not have to be entered 

or more processes. The proxy.dll 184 "marshals" the request in DGateAce 226, but can be manually entered later m the 

parameters into an independent format so that they may be 45 IDL file 222, before compilation. 

provided by the client process 186 over the COM-based DGateAce 226 also requires a function template 200, such 
interface 185, which conforms with the Microsoft DCOM as the one provided with DGateAce 226, which provides 
Model. The stub.dil 182, which also understands how to DGateAce 226 with a generalized framework for the gen- 
communicate over the common interface 185, "un- eration of an output function file 224. A customized function 
marshals" the parameters into a format that can be under- jq template can be used in place of the template provided by 
stood by the DCOM Server Application.exe 170. Thus, the DGateAce 226. 

DCOM environment allows machines with entirely different Finally, DGateAce 226 requires a set of information 

architectures (PCs, Workstations, etc.) to communicate which is interactively provided by an application developer 

using a common interface. 214 during the DGateAce 226 generation process. This set 

The specifics of the common interface are described in an 55 of information includes interface names and function names. 

Interface Definition Language (IDL) 174. The IDL 174 is As mentioned ear her, the DGateAce tool 226 will produce 

operated on by the Microsoft Interface Definition Language Interface Definition Language (IDL) files 222 as output. 

(MIDL) compiler 176 to create a set of .c (C) and .h (header) These IDL files 222 are source files defining the interface for 

files 178. Then, a second compiler (C++) 180 operates on the a DCOM appUcation. After generation of the IDL files 222 

.c and .h files to create the sUib.dll 182 the proxy.dll 184, and so by the DGateAce tool 226, the IDL files are compiled to 

the DCQM Server Application executable (.exe) 170. The produce a proxy/stub source file used by the DCOM Client/ 

proxy.dll 184 is linked to the DCOM Client Application Server application, a UUID source file, and a set of header 

executable (.exe) 186, and the stub.dil 182 is linked to the files. 

DCOM Server Application executable (.exe) 170. The DGateAce tool 226 also produces function files 224 

Once the stub.dil 182 un-marshals the parameters, the 65 as output from its generation process. These function files 

parameters are packaged into a single buffer by DCOM 224 server as source files for modules of the DCOM Server 

Server AppUcation executable (.exe) 170 and passed to the application. There is typicaUy one function file 224 gener- 
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aied for each unique combination of Open/OLTP service parameters will be provided to the service. In particular, the 

name, input view buffer, and output view buffer. view files 516 and 518 indicate where each input/output 

FIG. 3 illustrates how Interface Definition Language parameter is located, and the size and type of each input/ 

(IDL) files generated by the fimction buUding tool of the o\iXpui parameter. 

present invention (DGatcAce) arc compiled by the ^ After the input and output view files 516 and 518 have 

Microsoft IDL compiler. As described previously in FIG. 2, been transferred to a location where DGateAce 506 can 

DGateAce 226 produces two types of output files: function operate on them, DGateAce 506 extracts the interface infor- 

files and Interface Definition Language (IDL) files 300. mation from the view files 516 and 518 and automatically 

Interface Definition Language (IDL) files 3O0 are source generates a source file that is compatible with the DCOM 

files which define the interface for the DCQM application. environment 500. This executable file is shown in FIG. 5 as 

After generation of the IDL files 300 by the DGateAce the DCOM Server 510. During the generation process, 

utility, the IDL files are provided as input through interface DGateAce 506 queries the user 508 for the type of Client(s) 

302 to a Microsoft Interface Definition Language (MIDL) 504 which will be using the Server 510 so that the Server 

compiler 304, which must be instaUed on the development 510 is tailored for receiving requests firom those types of 

workstation. The MIDL compiler 304 is included as part of Clients 504. These Oicnts 504 may include Visual Basic, 

the Microsoft Windows Software Development Kit (SDK). C++, and/or Web Browsers with Active Server Pages 

The MIDL compiler 304 produces four types of output files. (ASPs). 

The first type of output file is the proxy/stub source file 314. The developer must next develop the application (Client) 

The proxy/stub source file 314 includes a proxy function for 504 running within the DCOM environment which gener- 

the DCOM client and a stub function for the DCOM Server. ates the request. This application (Client) 504 will include a 

The second type of output file is an interface UUID source standard call 522 to the Server 510. 

file 318. An interface UUID source file 318 provides UUIDs When a standard call 522 is made from an application 504 

for the DCOM client program. The third type of output file running under DCOM to the DCOM Server 510, the Server 

produced by the MIDL compiler 304 is a header file 316. 510 will correctly format (pack) the request parameters, and 

The header file (.h) 316 is used in the compilation of the pa^g the formatted parameters via interface 526 to the 

DCOM Client and Server source code. Finally, the last file DGate_Server.dll Dynamic Link Library (DLL) 512. The 

produced by the MIDL compiler 304 is a ddldata.c file 320. dll 512 verifies that the input parameters can be read, and 

The ddldata.c file 320 provides the proxy/stub with entry- verifies that the output parameters can be written. The DLL 

point information. 512 then appends additional parameters to the request and 

FIG. 4 illustrates how the output files from the fiinction forwards the request to the DGate.exe component 514 via 

building tool (DGateAce) of the present invention are used interface 528. DGate.exe 514 uses parameter information to 

during the compilation and linking of the DCOM Server correaly forward the request to the 2200 enterprise system 

module 432. In order to successfully compile and link the 502, The requested service 520 is performed on the 2200 

components of the DCOM Server 432, a C or C++ compiler enterprise system 502, and a response is sent back to 

410 and object linker 428 must be installed on the devel- Dgate.exe 514 via interface 532. DGate.exe checks for time 

opment workstation. There are three major input compo- out or disconnect conditions and returns the service response 

nents provided to the C or C++ Compiler 410: 1) source via interface 528 to the DGate_Server.dll 512. The DGate__ 

code for the main program of the DCOM server application, Server.dU 512 checks for successful completion of the 
written by the developer 400, 2) the function files 224 ^ operation and passes the response to the Server 526 via 

produced by the DGateAce tool, as i^own in FIG. 2, and 3) interface 526. The Server 526 checks completion codes and 

The header file 316 produced by the MIDL compiler, as passes the response to the requesting client 504 via interface 

shown in FIG. 3. The outputs of the C or C++ Compiler 410 522. 

are an object file (.obj) for the main program 420 and a set Jq i^^^ manner, a C, C++, Visual Basic, or some other type 
of object files (.obj) for the fiinctions 416. These two object of application 504 running on a Microsoft Windows NT or 
files 420 and 416 are then linked with the DGate Server Microsoft Windows 95 system is provided access to user- 
library file (DGate_Server.lib) 418 through the linker mod- developed services 520 running on an enterprise server 502. 
ule 428 to create the DCOM Server executable program 432. -phe developer does not need to understand the interface 

no. 5 is a diagram which indicates the interrelationships between the two systems 500 and 502 because this infor- 
between the DGate gateway and DGateAce tool. The auto- jq mation is automatically included within the automatically- 
mated development system the of present invention allows generated interface software components, 
developers to develop appHcations, or "services", on an pjc. 6 is a generalized flow diagram of the process flow 
enterprise server. In this case, OLTP applications are devel- tij^ function building tool (DGateAce). After the 
oped on a Unisys 2200 enterprise system 502. Ideally, these DGateAce tool starts, it first displays a DGateAce: DCOM 
applications will be available to end users executing within 55 interface Definition Form 602. This form 602 is used to set 
a DCOM environment 500. up an interface definition for the Server. A user will supply 

Under the development system of the present invention, a data 608 for this form by providing the following types of 

developer must still understand how to create a service on information: IDL header information, gateway name, inter- 

the enterprise system 502. An example of a service may be face name, transaction type, data type, and selection of a 
retrieval of data fi-om a database associated with the 2200 $0 template file 618. This user supplied input data 608 is passed 

enterprise On-Line Transaction Processing System (OLTP) onto both the module which retains interface user input for 

520. later file generation 600, and the module which retains 

After a developer has completed development of a service function specific user input for later file generation 634. 

520 on the Unisys 2200 system 502, the developer transfers When the user selects a template file 618, the template file 
the service input 516 and/or output view files 518 to a 65 618 is also passed onto the module which retains interface 

locations where they can be accessed by the DGateAce tool specific user input for later file generation 600, along with 

506, The view files 516 and 518 define how the input any appropriate template data 620. 
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Upon completion of the interface ^ecific user screen 602, 
the DGateAce tool advances to the DGateAce: DCOM 
Function Definitions form 622. This form 622 is used to 
build functions for the interface. On this form a developer is 
queried to input the required service name for the transaction 5 
to be translated to DCOM/OLE. The developer is also 
prompted for the input and output (optional) view file 
locations, and the OLTP input and output views the devel- 
oper wants included in the fiincuon. Finally, the developer is 
asked to provide select function-based attributes. A devel- 10 
oper provides this input data 628 to the module which retains 
function specific user input for later file generation 634. 
Information may also be passed to the module which retains 
function specific user input for later file generation 634 from 
the module which retains interface specific user input for 15 
later file generation 600. 

Upon completion of processing of the interface specific 
and function specific input data, control next passes to a 
module which generations output file pairs based on the user 
provided input 636 via interface 632. This module 636 will 20 
generate one pair of output files for each interface specified 
644. The pair of output files includes a code (functions) file 
642 and an Interface Definition Language (IDL) file 646. 

FIG. 7 is a detailed flow diagram of the process flow of 
the function building tool (DGateAce), which specifically 25 
shows interrelationship between interactive user queries and 
the function definition. The DGateAce tool behaves like a 
wizard, prompting the developer for information it needs to 
build base server source code files or modules that call 
TransIT Open/0 LTP transactions. The DGateAce tool 3^ 
prompts the developer through three data input forms: a 
DCOM Interface Definition form 704, a Function Defini- 
tions form 732, and a DCOM Functions Summary form 762. 
The DGateAce tool creates and saves Interface Definition 
Language (IDL) files 712 and function definition files 766. 
These files are the basis for the DCOM Ghent and Server 
code modules access by the DGate feature in the WebTX 
product. The DGate feaUire is packaged with the WebTX 
product as part of the Integrated Operating Environment 
(lOE) and is installed on the Windows NT node of a Unisys 
ClearPath IX Server. The DGateAce tool is packaged with <o 
the PathMate product as a solution. 

la order to successfully run the DGateAce utifity, the 
utihty needs access to certain files locally or through net- 
work connections to a workstation. A developer must 
specify the location of the OLTP view buffers, otherwise 45 
known as "view files" (not shown), specify the location of 
any custom function templates 702 associated with the 
cUent/server function code files, and be able to save the 
DGateAce generated IDL files and function definition files 
712 and 766. 50 

After starting the DGateAce tool, a user is first presented 
with a DCOM interface definition form 704. This form will 
prompt the user to enter IDL header information, a gateway 
name, interface name, transaction type, data type, and a 
template file. Upon completion of the interface definition 
form 704, a user is presented with several choices. The user 
may choose to exit the tool 710, without saving any of the 
information. The user may decide to utilize the browse 
function 726 from the "open/save as common dialog" 744 to 
select a function template file. The user can also choose to 
save the IDL file 712 via the open/save as common dialog 
744. Finally, a user may wish to proceed to the next step in 
the definition process, namely building functions 724. If a 
user chooses to continue to the build fiinctions 724 portion 
of the DGateAce tool, the developer is next presented with 
the DCOM Function Definitions form 732. On this form 732 65 
the developer is prompted to input the required OLTP 
service name for the transaction to be translated to DCOM/ 
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OLE, to select input and output view file locations, to choose 
the OLTP input and output views that are to be included in 
the function, and to select function-based attributes. The 
user may choose browse 740 to select input and output view 
files via the "open/save as common dialog" 744. 

Once the user has provided the necessary input to the 
DCOM function definitions form 732, the user may build the 
function 738. A developer advances to the DCOM Functions 
Summary form 762 when the developer cticks the build 
function 738 pushbutton and answers "NO" to a message 
asking if the developer wishes to build another function on 
file DCOM Fimction Definitions Form 732. From within the 
DCOM Functions Summary Form 762, a developer may 
return to the DCOM Function Definitions Form 732 by 
choosing the "OK" pushbutton 758, display all of the 
functions defined for the current function file in a list box, 
"ADD" 770 or "DELETE" 772 the individual fiinctions 
created by the DGateAce tool, or save the function definition 
766 via the "open/save as common dialog** 744. By clicking 
the "ADD" pushbutton 770, the process flow will return to 
the DCOM Function Definitions Form 732, so that the 
developer can create another function for the current func- 
tion file. 

In order to verify that the DGateAce tool successfuUy 
wrote the interface definition and function definition files, 
the developer may open Explorer under Microsoft Windows 
95 to see that the Interface Definition Language (IDL) files 
and source code (.c) files exist in the appropriate directory 
and file name locations, and may also verify that the date and 
time stamps on the files are current. To verify that the 
DGateAce tool generated the proper code, the Interface 
Definition Language (IDL) code can be used as a function 
prototype for the C++ wizard and the source files (.c) should 
successfully compile with the C/C++ compiler. 

Having thus described the preferred embodiments of the 
present invention, those of skill in the art will readily 
appreciate that the teachings found herein may be applied to 
yet other embodiments within the scope of the claims hereto 
attached. 

What is claimed is: 

1. In a data processing system having a Distributed 
Component Object Module (DCOM) environment con- 
nected to an enterprise On-Line Transaction Processing 
(OLTP) system, the improvement comprising: 

means coupled to said DCOM environment for building a 
set of functions which allow an appfication residing 
within said DCOM environment to access an associated 
service on said On-Line Transaction Processing 
(OLTP) system; 

wherein an application residing on said enterprise 
On-Line Transaction Processing (OLTP) system has an 
associated set of input and output view files which 
define how parameters will be provided to and received 
from said OLTP system; 

wherein said view files indicate where each said param- 
eter is located in the view file, and the size and type of 
each said parameter; and 

wherein said view files arc copied from said enterprise 
OLTP system to said DCOM environment prior to 
invocation of said function building means, 

2. A data processing system according to claim 1 wherein 
said function building means extracts interface information 
from said view file and generates a set of source files which 
is compatible with said DCOM environment. 

3. A data processing system according to claim 2 wherein 
during said generation of said source files, a user is queried 
about a type of client that wiU be using said source files, 
thereby allowing said source files to be ^ecificaUy tailored 
to receive requests from the type of cUent specified by- the 
user. 
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4. A data processing system according to claim 3 wherein 
said set of generated source files includes Interface Defini- 
tion Language (IDL) files which define an interface for a 
DCOM Client application. 

5- A data processing system according to claim 4 wherein ^ 
said IDL files are compiled by a Microsoft Interface Defi- 
nition Language (MIDL) compiler, which produces a set of 
MIDL output files. 

6. A data processing system according to claim 5 wherein 
said set of MIDL output files includes at least one proxy/stub 
source file that has a proxy fimction for use with said DCOM lO 
Client application, and a stub function for use with a DCOM 
Server. 

7. A data processing system according to claim 5 wherein 
said set of MIDL output files includes an interface Universal 
Unique Identifier (UUID) source file that provides UUIDs ^5 
for said DCOM Client application. 

8. A data processing system according to claim 5 wherein 
said set of MIDL output files includes at least one header file 
that is used in the compilation of said DCOM Client 
application and a DCOM Server. 

9. A data processing system according to claim 5 wherein 
said set of MIDL output files includes a Dynamic Data Link 
(DDL) data file which provides entry point information to a 
proxy function and a stub function. 

10. A data processing system according to claim 3 
wherein said set of source files includes function files which 25 
are module source files for a DCOM Server application. 

U. A data processing system according to claim 10 
wherein there is one said function file for each unique 
combination of Open/OLTP service name, input view buffer, 
and output view buffer. 30 

12. A data processing system according to claim 3 
wherein inputs used to generate said source files include a 
function template, Opcn/OLTP service names from an Open/ 
OLTP application, said view files, a set of interface names 
and function names provided by the user, and a set of 35 
Universal Unique Identifiers (UUIDS) produced by a UUID 
generator in an Open/OLTP gateway. 

13. A data processing system according to claim 3 
wherein said type of cHent is a Msual Basic client. 

14. A data processing system according to claim 3 
wherein said type of chent is a C++ application client. 

15. A data processing system according to claim 3 
wherein said type of cHent is a Web Browser with Active 
Server Pages (ASPs). 

16. A data processing system according to claim 3 
wherein a client application running within the DCOM ^5 
environment includes a standard call to a DCOM Server 
application. 

17. A data processing system according to claim 4 
wherein said enterprise OLTP system is a Unisys 2200 series 
mainframe computer. 50 

18. An apparatus for the automated development of a set 
of functions which allow an appUcation residing within a 
Distributed Component Object Module (DCOM) environ- 
ment to access an associated service located on an enterprise 
On -Line Transaction Processing (OLTP) system having: 

at least one view file residing on said enterprise OLTP 
system which defines how parameters will be provided 
to and received from said OLTP system; 

a file transfer mechanism to move said view file from said 
OLTP system to said DCOM environment; go 

an automated development utility which will operate on 
said view file to produce at least one output source file 
used in the creation of DCOM Client/Server applica- 
tions; and 

wherein said automated development utility will query a 65 
user about a type of cfient that will be using said source 
files, thereby allowing said output source files to be 



specifically tailored to receive requests fi-om the type of 
client specified by the user. 

19. An apparahis according to claim 18 wherein said 
output source files include Interface Definition Language 
(IDL) files which define the interface for a DCOM Client 
appUcation. 

20. An apparatus according to claim 19 wherein said IDL 
files are compiled by a Microsoft Interface Definition Lan- 
guage (MIDL) compiler, which produces a set of MIDL 
output files. 

21. An apparatus according to claim 20 wherein said set 
of MIDL output files includes at least one proxy/stub source 
file that has a proxy function for use with said DCOM Client 
application, and a stub function for use with a DCOM 
Server. 

22. An apparatus according to claim 20 wherein said set 
of MIDL output files includes an interface Universal Unique 
Identifier (UUID) source file which provides UUIDs for said 
DCOM Client application. 

23. An apparatus according to claim 20 wherein said set 
of MIDL output files includes at least one header file that is 
used in the compilation of said DCOM Chent application 
and a DCOM Server. 

24. An apparatus according to claim 20 wherein said set 
of MIDL output files includes a Dynamic Data Link (DDL) 
data file which provides entry point information to a proxy 
function and a stub function. 

25. An apparatus according to claim 19 wherein said 
output source files includes function files which are module 
source files for a DCOM Server application. 

26. An apparatus according to claim 19 wherein inputs 
used to generate said output source files include a function 
template, Open/OLTP service names from an Open/OLTP 
application, said view file, a set of interface names and 
functions provided by the user through the query, and a set 
of Universal Unique Identifiers (UUIDs) produced by a 
UUID generator in an Open/OLTP gateway. 

27. In a data processing system having a Distributed 
Component Object Module (DCOM) environment con- 
nected to an enterprise On-line Transaction Processing 
(OLTP) system, a method for the interactive, simplified 
creation of functions needed to access OLTP services from 
a DCOM Chent appUcation, comprising the steps of: 

creating a service on said OLTP system, including the 
creation of service input and output view files; 

transferring said service input and output files from said 
OLTP system to said DCOM environment such that 
said service input and output view files can be accessed 
by a function builder utiUty; 

reading said service input and output view files and 
extracting interface information from said service input 
and output view files via said function builder utility; 

generating a set of source files that are compatible with 
said DCOM environment via said function builder 
utility; 

building a DCOM client appUcation within the DCOM 
environment which includes standard calls to said 
source files generated by said function builder utihty; 
and 

compiUng a set of IDL source files generated by said 
fiiticlion builder utiUty with a Microsoft Interface Defi- 
nition Language (MIDL) compiler, such that a set of 
MIDL output files is created. 

28. A method according to claim 27 wherein said set of 
MIDL output files includes a proxy/stub source file that 
includes a proxy fiinction for the DCOM CUent appUcation 
and a stub function for a DCOM Server. 

29. A method according to claim 27 wherein said set of 
MIDL output files includes an interface Universal Unique 
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Identifier (UUID) source file that provides UUIDs for said 
DCOM client application. 

30. A method according to claim 27 wherein said set of 
MIDL output files includes a header file that is used in the 
compilation of said DCOM client application and server 
source code. 
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31. A method according to claim 27 wherein said set of 
MIDL output files include a Dynamic Link Library (DLL) 
data file that provides entry point information to a proxy/ 
stub function. 

4c * 4 * * 
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